Embodiments of the present invention relate to service-oriented computing, and more particularly relate to techniques for dynamic service invocation and dynamic service adaptation in the context of a service-oriented application.
In recent years, many organizations have adopted Service-Oriented Architecture (SOA) for building and integrating their business applications. Generally speaking, SOA is a software model that encapsulates business functionality into a collection of modular software components, known as services. Each service exposes a well-defined interface that is independent of the service's underlying implementation (e.g., hardware/software platform, programming language, etc.). Using these interfaces, the various services can interact to provide services to, and consume services from, each other.
One advantage of the SOA paradigm is that business applications can be structured as compositions of one or more component services. These types of applications are referred to herein as service-oriented applications. For example, an order fulfillment application may be configured to access (1) an internal query service for retrieving the details of a customer order, (2) an external credit verification service for checking the customer's credit, (3) an internal inventory service for reserving the items included in the order, and (4) an external shipping service for processing shipment. The structural definition of a service-oriented application (including, for example, the types of services accessed, the sequencing of service operation invocations, and fault handling) is typically expressed in an orchestration language, such as Business Process Execution Language (BPEL). A BPEL-based definition of a service-oriented application is known as a BPEL process.
One limitation with accessing services from a BPEL process is that the links to the services (i.e., partner links) are generally static. In other words, the specific service operation being invoked, as well as the name and location of the service exposing the operation, is statically defined by the process developer at design time. Although this approach may be suitable for smaller or highly targeted systems, in larger, more complex systems this approach can be problematic for several reasons. First, the particular service and/or service operation that needs to be invoked via a partner link may not be known at design time. This may occur if, for example, the BPEL process needs to select a service from among a plurality of services based on one or more runtime attributes. As a result, all of the possible services must be associated with separate partner links, and the business logic for deciding which partner link to use must be built into the BPEL process itself. Second, as service interfaces change or as new services are made available, the BPEL process grows more and more unwieldy because changes to the partner links require modification of the entire process. Third, since the business logic for selecting partner links is embedded within the BPEL process, it cannot be easily changed by users that do not have a sophisticated technical knowledge of BPEL and SOA.
Some of the above problems can be mitigated, to an extent, by using a feature of BPEL known as dynamic binding. Dynamic binding allows the service name and location associated with a partner link to be modified at runtime. However, dynamic binding does not allow dynamic modification of the service operation being invoked via the partner link. Thus, dynamic binding cannot be used to dynamically access different services that expose different operations; rather, all of the services must expose the exact same operation. This is problematic because many third-party services expose operations that are functionally similar, but have different operation names and/or message schemas.